NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/1630

Internet Message Format | 1996-08-06 | 5.8 KB

Path: zeus.clr.com!not-for-mail
From: [e-mail] (Phil Howard)
Newsgroups: comp.edu,comp.lang.c,comp.lang.c++
Subject: Re: C or C++ for a 14-year old?
Date: 11 Jan 1996 18:42:39 -0600
Organization: fasttax.com
Message-ID: <4d4apv$[e-mail]>
References: <4b30ld$lp2$[e-mail]> <[e-mail]> <[e-mail]> <4cq6cr$[e-mail]> <4cqhu3$[e-mail]>
NNTP-Posting-Host: zeus.clr.com

[e-mail] (William Hutto) writes:

| In article <4cq6cr$[e-mail]>,

...

| >    My choice would be C++, for two simple reasons:  With a porper string
| >classs, you eliminate the need for C's rather insane "string as an
| >array of really tiny integers" model, the #1 cause of trouble among
| >beginning C programmer.  In fact, with a standard class library that's
| >in any way competnet, you can virtually do with any pointers in your
| >code (the #2 cause of trouble).  And with new/delete with those rare
| >cases where you insist on having a pointer, you avoid the troble of
| >malloc/free (#3 cause of trouble...)
| >
|
| What am I doing in this thread???
|
|     I would recommend either BASIC or batch programming. Not for long
| though. The first ideology of programming is setting down a list of
| instructions for the system to carry out. When it comes to sequential flow,
| BASIC or batch processing would be the easiest to learn in my opinion; and
| with that learning comes the confidence of achievement, considering the
| student has generated something useful. They could then go on to learn
| conditional expressions and loops, and even subprograms.

...

|     The ultimate *destination* might be a commonly used/accepted language.
| I went from BASIC to 6502 assembly language, 8086 assembly language, C, C++
| and then Pascal. When I got to Pascal I thought, "Oops, wrong way!"
|     I almost wanted to say, start with assembler. Coming from assembler, I
| really understand what's happening with C (pointers took me about 5 minutes to
| understand). That is, I'm much more understanding of the efficiency of the C
| language. With C++, it's somehow vague as to just what the compiler is going
| to generate. I don't want to spend time learning the compiler's quirks. I'm
| much more *in tune* with the physical or *real* aspects of *the machine* and
| C++ is rather abstract. Although, on the other hand, C++ was a good lesson
| for me in abstraction and it's benefits, and is superb for modeling the *real*
| world as well as the GUI.


Depending on the intelligence and learning speed of the student, the course
through assembly may be better.  Anyone wanting to design hardware, drivers,
operating systems, and some kinds of library code, as well as system
administrators that want to really know what is going on under the hood,
I highly recommend assembly/machine language.

Once the student understands the basic idea that the computer can follow
instructions and does them literally, and when an environment can be had
to allow one to build up from code segments to full machine language
programs, then they should learn this programming.  I would recommend
learning both a CISC (80x86 or 680x0) and a RISC (AXP, MIPS, PPC, etc)
machine.

Then come back and learn C/C++.  Once assembly is mastered and understood,
things like arrays if bitty little integers, and incrementing pointers and
such will fall into place.  I learned C after I had learned assembly on
about 4 different machines, and I never had a problem with pointers or
arrays at all.  So, yes, that experience can make a big difference.

At the same time the student needs to remain aware of, and be able to work
with, abstract concepts.  One is doing well to implement linked lists and
binary search trees in assembly.  I've done that (including the trick with
XOR'd pointers to implement doubly linked lists with one pointer per node).
I'd even dabbled around in object oriented programs in assembly.  Remember,
object oriented programming is a abstract attitude and object oriented
languages are just tools to do that with.  You don't need C++ or other OOPs
to do OO programming, though it is usually easier if you are just doing
applications.

You should try to get an understanding of the student's goals to determine
just what level they need to be learning at.  Maybe they need to be building
digital circuits!

I remember when I was a kid in the 60's looking at these Heathkit project
toys.  They were a flat pressboard of circuit parts.  Add batteries and
clip wires into the springs attached to each part in the right arrangement
and you have various circuits.  I got one for Christmas and learned much
with it.

But there was one very interesting thing about the way I perceived this
project kit BEFORE I got one.  Keep in mind I was about 7 years old at
the time.

The picture was very unclear in the catalog and some of the words in the
description I was still not good at reading.  I could see in the picture
that parts could be wired together.  However I could not recognize most
of the actual parts for what they were, yet, and didn't really understand
the roles that things like resistors and capacitors play in circuits.

What I THOUGHT these parts were is switches!  I imagined doing projects
with and-logic and or-logic and even xor-logic, although at age 7 in the
early 60's, I had no names for these thoughts in my head.  I just wonder
where I would be today had someone come along with a real digital circuits
project toy and showed me how to program computers (punch boards would have
been great for me then).
--
Phil Howard KA9WGN      +-------------------------------------------------+
Unix/Internet/Sys Admin |    The enemy of my enemy is NOT my friend...    |
CLR/Fast-Tax            |        ...but he is a convenient ally!          |
[e-mail]            +-------------------------------------------------+